SPEC-DDD-SAL · v0.6
28 June 2026
Owner: Platform team

Sales — the prospect-to-cash bounded context

The context that turns a relationship into revenue: a centralized contact graph of everyone we deal with, the lead raised off a contact, the opportunity it becomes — with comparable variants — and the deal a chosen variant confirms into, quoted and closed. It also owns the partner channel — program tiers and reseller↔distributor distribution. A supporting subdomain whose distinctive parts (the channel, the relationship graph) are modeled with extra care.

1Responsibility & boundary

Sales is responsible for the whole journey before provisioning — from first contact to a confirmed, quotable deal — plus the partner sales channel. Its model is deliberately kept apart from operational identity: prospects, the wider buying network and people with no login live in the contact graph, which bridges to Federation's Tenant / ApplicationUser on conversion but never becomes it. The won deal hands off to provisioning by event, reaching into no other context's store. What Sales owns:

2Ubiquitous language

The words Sales uses — the same in code, conversation and spec. Each is precise to this context: "channel", "variant" and "bridge" mean exactly this here.

3Aggregates & invariants

The model's consistency boundaries. Each aggregate has one root entity — the only thing referenced from outside — and guards its invariants in one transaction. Cross-aggregate ties are by identity (an id), never a shared object graph.

4Context relationships

How Sales meets its neighbours, with the integration pattern named on each edge. The conversion bridge is an anticorruption layer — the single most important decision keeping the contact graph clean of tenancy.

5Domain events

The past-tense facts Sales publishes (and consumes). deal.won is the most consequential fact on the backbone — the provisioning saga's trigger.

6Invariants in play

The modeling rules that bind this context — the master holds the full set; entity-level integrity stays with the ERD.

7Physical view — the Sales service API

The deployment mapping, distinct from the model above: the Sales context becomes the Sales service, exposing these routes behind the gateway. All paths relative to api.riversync.com/v1; access notation per the master.

8Revision history

Version	Date	Changes
0.1–0.3	Jun 2026	Split proposed; partner channel registry took up residence here (PartnerProfile, DistributionAgreement) on the Agreement→Maintenance rename.
0.4	28 Jun 2026	Owns the CRM front of the funnel (SAL-1…8) — Contact, ContactRelationship, Campaign, Lead, Opportunity, OpportunityVariant and Activity, bridging to (never replacing) Federation's Tenant / ApplicationUser (SVC-18). New events and /sales/contacts · /leads · /opportunities · /activities routes.
0.5	28 Jun 2026	Reframed as a Domain-Driven Design context (with the set, SPEC-DDD v0.14). Leads with the model: ubiquitous language (§2), seven aggregates with their roots & invariants — Contact, Lead, Opportunity, Deal, PartnerProfile, DistributionAgreement, Activity (§3), the context relationships naming the ACL conversion bridge, the Maintenance partnership and the Billing/Devices customer/supplier links (§4), and the domain events as published language (§5). Classified a supporting subdomain. The /sales API is demoted to the physical view (§7). New Sales PRD (SPEC-PRD-SAL) is the requirement twin. No ownership change.
0.6	28 Jun 2026	Conversation forwarding. New domain event conversation.forwarded (Scope conversation | thread) and a POST /sales/conversations/{id}/forward route — a Forward (the conversation) or Forward all (the entire thread, every message) goes out on the conversation's own channel and writes an Activity. Cascaded from SPEC-PRD SAL-9 (amended) / SPEC-APP-PIP PIP-15 / SPEC-ERD DM-54. Catalog-driven — domain-catalog.js & domain-routes.js re-render.